Summary

Fix Direct Boot startup so KeyMapper does not initialize credential-encrypted database-backed components before the user has unlocked the device.

The root cause found during Q25 testing was that LOCKED_BOOT_COMPLETED started the app process and then called BaseKeyMapperApp.onBootUnlocked(), which initialized normal app components while user 0 was still RUNNING_LOCKED. That path could open /data/user/0/.../databases/key_map_database before credential-encrypted storage was available, causing repeated SQLiteCantOpenDatabaseException crashes.

This PR now:

• avoids app-wide Direct Boot awareness and marks the accessibility service as not Direct Boot aware
• keeps app/service Hilt dependencies lazy enough that a Direct Boot process start does not eagerly construct CE/database-backed objects
• delays accessibility controller creation until UserManager.isUserUnlocked
• stops calling onBootUnlocked() from LOCKED_BOOT_COMPLETED
• calls onBootUnlocked() from normal BOOT_COMPLETED, which is delivered after unlock

Reproduction

Tested on a Zinwa Q25 running BenOS Uma.1.

Installed KeyMapper 4.2.0-foss over the ROM-provided 3.2.1-foss system app, with KeyMapper Accessibility enabled and no external workaround app installed.

After reboot, before first unlock:

User 0: RUNNING_LOCKED
enabled_accessibility_services includes:
io.github.sds100.keymapper/io.github.sds100.keymapper.system.accessibility.MyAccessibilityService

Logcat shows KeyMapper trying to open CE storage before unlock:

Failed to ensure /data/user/0/io.github.sds100.keymapper/databases: mkdir failed: errno 126 (Required key not available)
SQLiteCantOpenDatabaseException: Cannot open database '/data/user/0/io.github.sds100.keymapper/databases/key_map_database'
Directory /data/user/0/io.github.sds100.keymapper/databases doesn't exist

On this device, the repeated Direct Boot crash/restart state appears to corrupt lockscreen physical-keyboard handling until the first unlock. Examples observed before first unlock:

• Harpocrat Keyboard typed letters as uppercase.
• Gboard/other keyboards duplicated characters.
• adb shell getevent -lt showed only one hardware key down/up event, so duplication occurred above the Linux input layer.

Device verification

Built and tested locally on the same Q25 using a debug build installed as io.github.sds100.keymapper.debug.

Before first unlock, after this fix:

• Android logs that the KeyMapper accessibility service is ignored as non-encryption-aware
• KeyMapper process may still start for the Direct Boot receiver
• BaseKeyMapperApp logs Delay init because locked
• no KeyMapper key_map_database open attempt or SQLite fatal occurs before unlock

After first unlock:

• KeyMapper logs onBootUnlocked then Init
• accessibility service remains enabled
• no crashed accessibility service is recorded

Why

This keeps KeyMapper available after the first unlock while preventing the broken Direct Boot/locked-user startup window from touching credential-encrypted app storage.